On Wed, 2012-08-01 at 01:06 +0000, Liubing (Leo) wrote:
> You mentioned the ambiguous M flag in RA, indeed this is a problem,
> and it has been disscussed in 6renum WG.
> 
> So if you're still consern about the issue, looking forward to hear
> some comments from you, either on the mics or in the mail.

[Leo sent me the above off list, but I post my reply here with his
permission]

Thanks!

A host should always be allowed to do DHCPv6 in the *absence* of
information to the contrary; this is no different to NOT doing DHCPv6 in
the absence of information. Also, a host may be in a self-contained or
isolated network, i.e., one without a router, but with a DHCP server. So
NOT receiving RAs is no reason NOT to do DHCPv6. Nor is it a reason to
do it either, of course - i.e., it's up to the host :-)

I'll preface all this my saying that I think the M and O flags as
generally implemented and used are pretty much useless. The best thing
to do with them would be to deprecate them altogether.

If they must be retained, then I feel that the semantics should be as
follows, and as far as I can tell from the RFC, this is all allowed:

The O and M flags are completely independent. The O flag implies nothing
about address configuration, and the M flag implies nothing about
whether ancillary information is available. Clarifying those points
alone would make the RFC much more useful.

A valid RA can contain both the O and the M flags.

The M and O flags are advisory:
   - a host MAY attempt to obtain an address via DHCPv6
     without seeing an RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - a host MAY attempt to obtain an address via DHCPv6 even
     if it sees an RA with no M flag. Rationale: Not all routers are
     necessarily "authoritative"; there may be multiple routers on a
     link, not all of which are advertising an available DHCPv6 server.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     without seeing a RA at all.  Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     even if it sees an RA with no M flag. Rationale: Not all routers
     are necessarily "authoritative"; there may be multiple routers on
     a link, not all of which are advertising an available DHCPv6
     server.

Once a DHCPv6 address has been configured or ancillary info obtained:
   - a host MAY deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag. Rationale: In the absence of
     any compulsory aspect to DHCPv6, the deconfiguration of addresses
     that were "voluntarily" acquired must logically be permitted.

   - a host SHOULD deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag IF that address was configured
     in response to an M flag. Rationale: If the reason the host
     configured the address was because it reacted to an M flag, then
     it should react to the absence of M flags by deconfiguring the
     address. That is, the host should be consistent in its approach
     to the M flag.

Once ancillary information has been obtained via DHCPv6:
   - a host MAY discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag. Rationale: In
     the absence of any compulsory aspect to DHCPv6, the disposal of
     ancillary information "voluntarily" acquired must logically be
     permitted.

   - a host SHOULD discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag IF that
     information was obtained in response to an O flag. Rationale: If
     the reason the host obtained ancillary information was because it
     reacted to an O flag, then it should react to the absence of O
     flags by discarding the information. That is, the host should be
     consistent in its approach to the O flag.

The above are the "non-strict" semantics. If a stricter approach is
needed, I suggest an additional flag that, if set, changes the M and O
flags from advisory to prescriptive. Let's call it the DHCP_STRICT flag.
The flag MUST default to FALSE. Because the *absence* of an M or O flag
is meaningful in strict mode, we also need a flag that indicates whether
the DHCP_STRICT flag itself is meaningful, let's call it
DHCP_STRICT_MODE. This flag defaults to FALSE.

If DHCP_STRICT_MODE is FALSE, then the value of the DHCP_STRICT flag is
not valid and a host should use the non-strict semantics.

If DHCP_STRICT_MODE is TRUE, then the value of the DHCP_STRICT flag is
valid, and the following semantics apply.

If DHCP_STRICT is FALSE, then a host MUST use the non-strict semantics.

If DHCP_STRICT is TRUE, then a host MUST use the following semantics.

The O and M flags are completely independent. The O flag implies nothing
about address configuration, and the M flag implies nothing about
whether ancillary information is available.

A valid RA can contain both the O and the M flags.

Once a host has seen an RA with DHCP_STRICT_MODE=TRUE and
DHCP_STRICT=FALSE, the host MUST ignore any subsequent RA with
DHCP_STRICT_MODE=TRUE and DHCP_STRICT=TRUE. A host MAY log a warning in
this case. This state MUST NOT be persistently stored. Rationale: Moving
from strict to non-strict is much less harmful than moving from
non-strict to strict, given that strict mode can require hosts to
deconfigure addresses or not acquire them in the first place. Not having
this state in persistent storage means that a reset of the network stack
or the host itself will clear the state, allowing it move from
non-strict to strict mode.

The M and O flags MUST be honoured if known:
   - a host MAY attempt to obtain an address via DHCPv6
     without seeing an RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - once it has seen an RA on a link, a host MUST NOT attempt to
     obtain an address via DHCPv6 unless it sees an M flag. Rationale:
     In strict mode, the M flag is prescriptive; no M flag = no
     DHCPv6 address configuration.

   - a host MAY attempt to obtain ancillary information via DHCPv6
     without seeing a RA at all. Rationale: The host may be in an
     isolated network, containing a DHCPv6 server, but no router.

   - once it has seen an RA on a link, a host MUST NOT attempt to
     obtain ancillary information via DHCPv6 unless it sees an O flag.
     Rationale: In strict mode, the O flag is prescriptive; no O flag =
     no ancillary information via DHCPv6.

Once a DHCPv6 address has been configured:
   - a host MUST deconfigure a DHCPv6 address if an RA is seen
     that does not contain an M flag. However, deconfiguration MUST
     be done by allowing the valid lifetime of the address to expire OR
     two hours to elapse, whichever is the lesser. Rationale: If the
     network is no longer advertising a DHCPv6 server, strict mode
     requires that hosts no longer use information obtained via DHCPv6.
     The delay provides some some hysteresis and also some protection
     against rogue RAs.

Once ancillary information has been obtained via DHCPv6:
   - a host MAY discard ancillary information obtained via DHCPv6
     if an RA is seen that does not contain an O flag. If an address
     has been obtained via DHCPv6, the host MUST wait and discard
     the ancillary information only at the next renewal of that
     address or after two hours, whichever is the lesser period.
     Rationale: If the network is no longer advertising a DHCPv6
     server, strict mode requires that hosts no longer use
     information obtained via DHCPv6. This delay provides some
     hysteresis and also some protection against rogue RAs.

A variant on strict mode is semi-strict, where you can specify "MUST do
DHCPv6" via the M flag, but you can't specify "MUST NOT" through its
absence. And mutatis mutandis for the O flag.

I don't personally feel that all this is necessary. Also, I think that
the security considerations relating to strict mode (and to your very
similar suggestions) make them dangerous. A rogue router could issue RAs
that cause hosts on a compromised link to not do DHCPv6 at all,
deconfigure DHCPv6 addresses and/or discard ancillary information. For
that reason I prefer the non-strict semantics.

How does all this interact with SLAAC? It doesn't. If you want your
hosts to do SLAAC, you set the autoconf flag; otherwise you don't. If
you don't want hosts in a subnet to do DHCPv6, configure your DHCPv6
servers to not provide addresses to that subnet.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687